Feature/prd 1032 Token authentication#645
Conversation
Automatic merge into master to Release 3.18.6
Automatic merge into master to Release 3.18.7
Automatic merge into master to Release 3.18.8
Automatic merge into master to Release 3.18.9
Automatic merge into master to Release 3.18.10
Automatic merge into master to Release 3.18.11
Automatic merge into master to Release 3.18.12
Automatic merge into master to Release 3.18.13
Automatic merge into master to Release 3.18.14
Automatic merge into master to Release 3.18.15
Automatic merge into master to Release 3.18.16
Automatic merge into master to Release 3.18.17
Automatic merge into master to Release 3.18.18
Automatic merge into master to Release 3.18.19
Automatic merge into master to Release 3.18.20
Automatic merge into master to Release 3.18.21
Automatic merge into master to Release 3.18.22
Automatic merge into master to Release 3.18.23
Automatic merge into master to Release 3.18.24
Automatic merge into master to Release 3.18.25
Update version to 3.18.25
Automatic merge into master to Release 3.18.26
Update version to 3.18.26
| - Patched the Web Share API on Android by overriding `navigator.canShare` and `navigator.share` in the WebView and forwarding share events via `postMessage` to be handled natively using the React Native Share API. | ||
| ### Added | ||
|
|
||
| - Added JWT token authentication support through `SitumPlugin.setToken()` and the new optional `SitumProvider.token` property. |
There was a problem hiding this comment.
Que opcion va a tener preferencia en mi app si llamo a las 2 en mi codigo ? Entiendo que la ultima que hayas llamado ? Cual seria la opcion "ideal" o mas normal/idiomatica de usar la autenticacion por token ?
There was a problem hiding this comment.
Exacto, se aplica la última a la que hayas llamado. La forma ideal de usarlo es por medio del provider, pues se integra con el flujo de React.
Por otro lado, aclaro que en el provider he hecho que el token tenga prioridad sobre la apikey para evitar posibles errores si mandas los 2 a la vez. A esto tampoco creo que haya que darle muchas vueltas, al final no se deberían utilizar apikey y token a la vez.
There was a problem hiding this comment.
Lo he cambiado, ya no hay prioridad, es siempre el último que pasas
There was a problem hiding this comment.
Yo reflejaria esta aclaracion en el changelog y en la docu del provider si tiene
| boolean isSuccess = false; | ||
| try { | ||
| if (token != null && !token.isEmpty()) { | ||
| isSuccess = SitumSdk.configuration().setToken(token); |
There was a problem hiding this comment.
es una tontería pero no está bien indentado
| }; | ||
|
|
||
| /** | ||
| * Provides your token to the Situm SDK. |
There was a problem hiding this comment.
Mira la documentación que tenemos en los sdks y adaptala para esto
| }, [auth, configuration.situmApiKey]); | ||
|
|
||
| const sendEffectiveAuth = useCallback(() => { | ||
| if ( |
There was a problem hiding this comment.
porque separas el if en tres lineas?
There was a problem hiding this comment.
Lo he cambiado, ahora lo subo
| } | ||
| }; | ||
|
|
||
| const effectiveAuth = useMemo<SitumAuth | undefined>(() => { |
There was a problem hiding this comment.
no entiendo esto del todo. useMemo no se utiliza para que no se vuelva a recalcular este valor?
There was a problem hiding this comment.
const effectiveAuth = useMemo<SitumAuth | undefined>(() => {...}, []) ➡️ se calcula una vez al crear el componente
const effectiveAuth = useMemo<SitumAuth | undefined>(() => {...}, [auth, configuration.situmApiKey]) ➡️ se calcula al crearse y cada vez que cambien auth y configuration.situmApiKey
There was a problem hiding this comment.
Eu tampouco o termino de entender de todo.
Que pasaría se
- O integrador mete apikey ou token no provider ou na configuración?
- O integrador mete token ou apikey invalido pero chama os setters?
| * Token renewal is the client's responsibility: update this property or call | ||
| * `SitumPlugin.setToken()` when a new token is available. | ||
| * | ||
| * If both `token` and `apiKey` are specified, `token` takes precedence. |
There was a problem hiding this comment.
esto ya no es así no? Sería el último que pases
There was a problem hiding this comment.
Lo he cambiado, ahora lo subo
| - Patched the Web Share API on Android by overriding `navigator.canShare` and `navigator.share` in the WebView and forwarding share events via `postMessage` to be handled natively using the React Native Share API. | ||
| ### Added | ||
|
|
||
| - Added JWT token authentication support through `SitumPlugin.setToken()` and the new optional `SitumProvider.token` property. |
There was a problem hiding this comment.
Lo he cambiado, ya no hay prioridad, es siempre el último que pasas
| export const { | ||
| setWebViewRef, | ||
| setSdkInitialized, | ||
| setAuth, |
There was a problem hiding this comment.
Los he quitado porque no se usaban en ninguna parte y no se estaban sincronizando con el estado del sdk, esta no es la manera intencionada de cambiar el auth y el usuario no debería poder marcar el sdk como no inicializado
There was a problem hiding this comment.
Teñen algo que ver cos _setAuth e _setSdkInitialized que están xusto arriba?
| const [state, dispatch] = useReducer(store.reducer, { | ||
| ...store.initialState, | ||
| user: { email, apiKey }, | ||
| apiDomain: apiDomain, |
There was a problem hiding this comment.
Ahora se comprueba que no den error en el sdk antes de guardarlos en la store. Si algo da error se quedan como undefined. De todas formas tampoco afecta en nada porque los hijos de este componente no aparecen hasta que se comprueba la autenticación y el api domain, pero así queda más limpio para el futuro.
There was a problem hiding this comment.
seguramente se me esta escapando algo, pero non termino de entender os cambios en apiDomain
| } catch (e) { | ||
| console.error(`SitumProvider > Could not update API domain ${e}`); | ||
| } | ||
| }, [apiDomain, dispatch]); |
There was a problem hiding this comment.
Hubo que separar los props en varios useEffect para que solo se haga el setToken o setApiKey cuando cambie la autenticación.
There was a problem hiding this comment.
Esto escápaseme un pouco pero non se poderia facer algo do tipo
if (token){
}
if (apikey){
} e detectar cambios en token, apikey e email
| <key>NSMotionUsageDescription</key> | ||
| <string>We use your phone sensors (giroscope, accelerometer and altimeter) to improve location quality</string> | ||
| <key>RCTNewArchEnabled</key> | ||
| <true/> |
There was a problem hiding this comment.
Porque se activa a nova arquitectura en iOS? De momento o plugin de AR non funciona coa nova arquitectura.
| if (token && token.length > 0) { | ||
| success = [SITServices setToken:token]; | ||
| } | ||
|
|
There was a problem hiding this comment.
Vexo que este método devolve un enteiro en lugar de strings como o resto dos métodos. Esto fixechelo asi porque senon o onCallback non funciona?
xa que export const
handleSyncCallback = (
r: { success: boolean },
errorMessage: string,
) => {
if (r?.success) {
return;
} else {
throw {
code: -1,
message: errorMessage || "Unknown error.",
};
}
}; espera bool e iOS devolve strings no resto dos metodos, non?
There was a problem hiding this comment.
Se cadra compensaba arranxa o hadleSyncCallback en lugar de cambiar o patron
| /* Users are intended to change these variables through SitumProvider's props */ | ||
| _setAuth: (state: State, payload: State["user"]) => { | ||
| return { ...state, user: payload }; | ||
| }, |
There was a problem hiding this comment.
Porque fai falla engadir o apiDomain, aqui?
| export const { | ||
| setWebViewRef, | ||
| setSdkInitialized, | ||
| setAuth, |
There was a problem hiding this comment.
Teñen algo que ver cos _setAuth e _setSdkInitialized que están xusto arriba?
| const [state, dispatch] = useReducer(store.reducer, { | ||
| ...store.initialState, | ||
| user: { email, apiKey }, | ||
| apiDomain: apiDomain, |
There was a problem hiding this comment.
seguramente se me esta escapando algo, pero non termino de entender os cambios en apiDomain
| } catch (e) { | ||
| console.error(`SitumProvider > Could not update API domain ${e}`); | ||
| } | ||
| }, [apiDomain, dispatch]); |
There was a problem hiding this comment.
Esto escápaseme un pouco pero non se poderia facer algo do tipo
if (token){
}
if (apikey){
} e detectar cambios en token, apikey e email
| } | ||
| }; | ||
|
|
||
| const effectiveAuth = useMemo<SitumAuth | undefined>(() => { |
There was a problem hiding this comment.
Eu tampouco o termino de entender de todo.
Que pasaría se
- O integrador mete apikey ou token no provider ou na configuración?
- O integrador mete token ou apikey invalido pero chama os setters?
No description provided.